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1 .  Introduction 

This  paper  shows  that  the  specification  and  verification  techniques  for  abstract  data  types  that  have 
been  successful  for  sequential  programs  can  be  extended  in  a  natural  way  to  provide  the  same 
benefits  for  concurrent  programs.  Our  two  main  contributions  are: 

•  New  techniques  for  using  (sequential)  axiomatic  specifications  to  reason  about 
concurrent  objects;  and 

•  A  novel  correctness  condition,  which  we  call  linearizability. 

Informally,  a  concurrent  system  consists  of  a  collection  of  sequential  processes  that  communicate 
through  shared  typed  objects.  This  model  is  appropriate  for  multiprocessor  systems  in  which 
processors  communicate  through  reliable,  high -bandwidth  shared  memory.  Whereas  “memory” 
suggests  registers  with  read  and  write  operations,  we  use  the  term  concurrent  object  to  suggest  a 
richer  semantics.  Each  object  has  a  type,  which  defines  a  set  of  possible  values  and  a  set  of  primitive 
operations  that  provide  the  only  means  to  create  and  manipulate  that  object.  We  can  give  an 
axiomatic  specification  for  a  typed  object  to  define  the  meaning  of  its  operations  when  they  are 
invoked  one  at  a  time  by  a  single  process.  In  a  concurrent  system,  however,  an  object’s  operations 
can  be  invoked  by  concurrent  processes,  and  it  is  necessary  to  give  a  meaning  to  possible 
interleavings  of  operation  invocations. 

Our  approach  to  specifying  and  verifying  concurrent  objects  is  based  on  the  notion  of  linearizabitity. 
A  concurrent  computation  is  linearizable  if  it  is  “equivalent,”  in  a  sense  formally  defined  in  Section  3, 
to  a  legal  sequential  computation.  We  interpret  a  data  type’s  (sequential)  axiomatic  specification  as 
permitting  only  linearizable  interleavings.  Instead  of  leaving  data  uninterpreted,  linearizability  exploits 
the  semantics  of  abstract  data  types;  it  permits  a  high  degree  of  concurrency,  yet  it  permits 
programmers  to  specify  and  reason  about  concurrent  objects  using  known  techniques  from  the 
sequential  domain.  Unlike  alternative  correctness  conditions  such  as  sequential  consistency  [17]  or 
serializability  [26],  linearizability  is  a  local  property:  a  system  is  linearizable  if  each  individual  object  is 
linearizable.  Locality  enhances  modularity  and  concurrency,  since  objects  can  be  implemented  and 
verified  independently,  and  run-time  scheduling  can  be  completely  decentralized.  Linearizability  is  a 
simple  and  intuitively  appealing  correctness  condition  that  generalizes  and  unifies  a  number  of 
correctness  conditions  both  implicit  and  explicit  in  the  literature. 

Using  axiomatic  specifications  and  our  notion  of  linearizability,  we  show  that  we  can  perform  two 
kinds  of  reasoning: 

•  We  reason  about  concurrent  computations  by  transforming  assertions  about  concurrent 
computations  into  simpler  assertions  about  sequential  computations.  Familiar  axiomatic 
techniques  help  prove  these  transformed  assertions. 


2 


•  Implementations  of  concurrent  objects  are  necessarily  more  complex  then  their 
sequential  counterparts.  We  reason  about  the  correctness  of  linearizable 
implementations  using  new  techniques  that  generalize  the  notions  of  representation 
invariant  and  abstraction  function  to  the  concurrent  domain. 

Section  2  presents  our  model  of  a  concurrent  system  and  specification  technique;  Section  3  defines 
and  discusses  linearizability,  including  its  locality  property;  Section  4  illustrates  reasoning  about 
concurrent  registers  and  queues;  Section  5  illustrates  reasoning  about  an  implementation  of  a 
concurrent  queue;  Sections  6  and  7  contain  discussions  on  related  work  and  the  significance  of 
linearizability. 


2.  System  Model  and  Specification  Technique 


2.1.  Histories 

An  execution  of  a  concurrent  system  is  modeled  by  a  history,  which  is  a  finite  sequence  of  operation 
invocation  and  response  events.  An  operation  invocation  is  written  as  x  op(args’)  A,  where  x  is  an 
object  name,  op  is  an  operation  name,  args ’  denotes  a  sequence  of  argument  values,  and  A  is  a 
process  name.  The  response  to  an  operation  invocation  is  written  as  x  ter m  (res ’)  A ,  where  term  is  a 
termination  condition,  and  res’  is  a  sequence  of  results.  We  use  “Ok”  for  normal  termination.  A 
response  matches  an  invocation  if  their  object  names  agree  and  their  process  names  agree.  An 
invocation  is  pending  in  a  history  if  no  matching  response  follows  the  invocation.  If  H  is  a  history, 
comp/efe(H)  is  the  longest  subhistory  of  H  consisting  only  of  invocations  and  matching  responses. 

A  history  H  is  sequential  if: 

1 .  The  first  event  of  H  is  an  invocation. 

2.  Each  invocation,  except  possibly  the  last,  is  immediately  followed  by  a  matching 
response. 

3.  Each  response,  except  possibly  the  last,  is  immediately  followed  by  an  invocation. 

A  process  subhistory,  H|P  (H  at  P),  of  a  history  H  is  the  subsequence  of  events  in  H  whose  process 
names  are  P.  An  object  subhistory  H|x  is  similarly  defined  for  an  object  x.  Two  histories  H  and  H’  are 
equivalent  if  for  every  process  P,  H|P  =  H’|P.  A  history  H  is  well-formed  if  each  process  subhistory 
H|P  of  H  is  sequential.  All  histories  considered  in  this  paper  are  assumed  to  be  well-formed.  Notice 
that  whereas  process  subhistories  of  a  well-formed  history  are  necessarily  sequential,  object 
subhistories  are  not. 

An  operation,  e,  in  a  history  is  a  pair  consisting  of  an  invocation,  inv(e),  and  the  next  matching 
response,  res(e).  An  operation  eQ  lies  within  another  operation  e1  in  H  if  invfe^  precedes  inv(eQ)  and 
res(eQ)  precedes  resfe.,)  in  H. 
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For  example,  let  H1  be  the  following  history: 

qEnq(x)A  (History  H.,) 

q  Enq(y)  B 
q  Ok<)  B 
q  Ok()  A 
q  Deq()  B 
q  Ok(x)  B 
q  Deq()  A 
q  Ok(y)  A 
q  Enq(z)  A 

H1  is  a  well-formed  history  for  a  FIFO  queue  q  providing  Enq  and  Deq  operations.  The  first  event  is  an 
invocation  of  Enq  with  argument  x  by  process  A,  and  the  fourth  event  is  the  matching  response  with 
termination  condition  Ok  and  no  results.  The  "q  Enq(y)  B/q  Ok()  B”  operation  lies  within  the 
“q  Enq(x)  A/q  Ok()  A”  operation.  The  subhistory,  complete^),  is  H1  with  the  last  (pending) 
invocation  of  Enq  removed.  Reordering  the  first  two  events  yields  one  of  many  histories  equivalent  to 

Hv 

2.2.  Specifications 

A  sequential  history  for  an  object  can  be  summarized  by  the  object’s  value  at  the  end  of  the  history. 
We  use  axiomatic  specifications  to  reason  about  object  values.  A  specification  is  a  set  of  axioms  of 
the  form: 

{P} 

op(args  *  )/term(res  *) 

{0} 

where  P  is  a  pre-condition  on  the  object's  value  and  the  argument  values  that  must  be  met  before  an 
invocation,  and  Q  is  a  post- condition  on  the  object's  value  and  the  result  values  that  is  guaranteed  to 
hold  upon  return  for  the  given  termination  condition.  Identifiers  in  args*  and  res'  denote  values  of 
arguments  and  results.  A  sequential  history  H  is  legal  if  for  all  object  subhistories,  H|x,  of  H,  each 
operation  in  H|x  satisfies  its  axiomatic  specification. 

The  axioms  presented  in  this  paper  are  essentially  Larch  interface  specifications  [10, 11]  for 
operations  of  abstract  data  types.  For  example,  axioms  for  the  Enq  and  Deq  operations  for  FIFO 
queues  are  shown  in  Figure  2-1.  The  queue's  value  before  the  operation  is  denoted  by  q  and  the 
value  after  the  operation  by  q'.  The  post-condition  for  Enq  states  that  upon  termination,  the  new 
queue  value  is  the  old  queue  value  with  e  inserted.  Notice  that  the  specification  for  Deq  is  partial: 
Deq  is  undefined  for  the  empty  queue. 

The  assertion  language  lor  the  pre-  and  pus;  conditions  is  based  on  the  Larch  Shared  Specification 
Language.  It  is  akin  to  algebraic  specification  languages  and  is  used  to  describe  the  set  of  values  of  a 
typed  object.  The  set  of  operators  and  their  signatures  following  introduces  defines  a  vocabulary  of 
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Axiom  E: 

{true} 

Enq{e)/Ok() 

(q‘  =  ins(q,  e)} 

Axiom  D: 

{-i  isEmp(q)} 

Deq()/Ok(e) 

{q*  =  rest(q)  A  e  =  first(q)} 

Figure  2-1:  Axioms  for  Queue  Operations 


QVals:  trait 
introduces 
emp:  — ►  Q 
ins:  Q,  E  -♦  Q 
first:  Q  -♦  E 
rest:  Q -*  Q 
isEmp:  Q  -♦  Bool 
constrains  Q  so  that 
Q  generated  by  [  emp,  ins  ] 
for  all  q:  Q,  e:  E 
first(ins(emp),  e))  »  e 

first(ins(q,  e))  =  if  isEmp(q)  then  e  else  first(q) 
restfinsfq,  e))  =  if  isEmp(q)  then  emp  else  ins(rest(q),  e) 
isEmp(emp)  *  true 
isEmp(ins(q,  e))  =  false 

Figure  2-2:  Trait  for  Queue  Values 

terms  to  denote  values.  For  example.  emp  and  ins(emp,  5)  denote  two  different  queue  values.  The 
set  of  equations  following  the  constrains  clause  defines  a  meaning  for  the  terms,  more  precisely,  an 
equivalence  relation  on  the  terms,  and  hence  on  the  values  they  denote.  For  example,  from  QVals,  we 
could  prove  that  rest(ins(ins(emp,  3),  5)  =  insfemp,  5).  The  generated  by  clause  of  QVals  asserts 
that  emp  and  ins  are  sufficient  operators  to  generate  all  values  of  queues.  Formally,  it  introduces  an 
inductive  rule  of  inference  that  allows  one  to  prove  properties  of  all  terms  of  sort  Q.  We  use  the 
vocabulary  of  traits  to  write  the  assertions  in  the  pre-  and  post-conditions  of  a  type’s  operations:  we 
use  the  meaning  of  equality  to  reason  about  its  values.  Hence,  the  meaning  of  “ins"  and  “  =  "  in 
Axiom  E's  post-condition  is  given  by  the  trait  QVals. 


3.  Linearizability 
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3.1 .  Definition 

Axiomatic  specifications  have  (as  yet)  no  meaning  for  histories  that  are  not  sequential.  This  section 
introduces  the  notion  of  linearizability,  the  basic  correctness  condition  that  allows  us  to  apply 
algebraic  specifications  and  axiomatic  reasoning  to  concurrent  objects. 

A  history  H  induces  an  irreflexive  partial  order  -<H  on  operations: 
eo  "“'H  ei fes(eo)  precedes  inv(et)  in  H. 

(Where  appropriate,  the  subscript  is  omitted.)  Informally,  -<H  captures  the  “real  time”  precedence 
ordering  of  operations  in  H.  Operations  unrelated  by  -<H  are  said  to  be  concurrent.  If  H  is  sequential, 

-<H  is  a  total  order. 

A  history  H  is  linearizable  if  can  be  extended  (by  appending  zero  or  more  events)  to  some  history  H’ 
such  that: 

LI :  complete(H’)  is  equivalent  to  some  legal  sequential  history  S,  and 
L2:  -<H.  C  -<s. 

LI  states  that  processes  act  as  if  they  were  interleaved  at  the  granularity  of  complete  operations.  L2 
states  that  this  apparent  sequential  interleaving  respects  the  real-time  precedence  ordering  of 
operations.  We  call  S  a  linearization  of  H. 

The  history  H1  shown  in  Section  2  is  linearizable,  because  H.,’  *  H1  •  q  Ok()  A  is  equivalent  to  the 
following  sequential  history: 

q  Enq(x)  A  (History  H^) 

q  Ok()  A 
a  Enq(y)  B 
q  Ok()  B 
q  Deq()  B 
q  Ok(x)  B 
q  Deq()  A 
q  Ok(y)  A 
q  Enq(z)  A 
q  Ok()  A 

The  following  history,  H2,  is  not  linearizable: 

q  Enq(x)  A  (History  Hj) 

q  Ok()  A 
q  Enq(y)  B 
q  Ok()  B 
q  Deq()  A 
q  01  (y)  A 

because  the  Enq  of  x  precedes  the  Enq  of  y,  but  y  is  dequeued  before  x. 

» 

Linearizability  does  not  rule  out  histories  such  as  the  following  history,  H3,  in  which  an  operation 
"takes  effect”  before  its  return  event  occurs: 
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q  Enq(x)  A  (History  H3) 

q  Deq()  B 
q  Ok(x)  B 

H3  can  be  extended  to  H3’  =  H3  •  q  Ok()  A,  which  can  be  shown  equivalent  to  the  sequential  history  in 
which  the  enqueue  operation  occurs  before  the  dequeue. 

Lamport’s  notion  of  sequential  consistency  [17]  requires  that  a  history  be  equivalent  to  a  sequential 
history.  Sequential  consistency  is  weaker  than  linearizability,  because  it  does  not  require  the 
precedence  ordering  -<  to  be  preserved.  For  example,  H2  is  sequentially  consistent,  but  not 
linearizable.  Serializability  [26]  requires  that  a  history  be  equivalent  to  a  sequential  history  in  which 
each  process  (usually  called  a  transaction)  runs  to  completion  without  interleaving  with  other 
processes. 1  Lamport  [19]  has  proposed  that  the  standard  definition  of  serializability  be  strengthened 
to  preserve  the  order  of  non  overlapping  transactions.  Both  notions  of  serializability  are 
incomparable  to  linearizability.  For  example,  H1  is  linearizable,  but  not  serializable  (in  either  sense), 
and  H2  is  serializable,  but  not  linearizable. 

3.2.  Locality 

Linearizability  is  a  local  property. 

Theorem  1 :  H  is  linearizable  if  and  only  if  H|x  is  linearizable  at  each  object  x. 

Proof:  The  “only  if"  part  is  obvious. 

From  the  assumption  that  each  object's  history  is  linearizable,  there  exists  for  each  object 
x  an  induced  total  order  <x  on  its  own  operations,  and  by  the  well-formedness  criteria  for 
histories,  each  process  P  induces  a  total  order  <p  on  its  operations.  We  claim  that  the 
transitive  closure  of  the  union  of  all  <x  and  <p  is  a  partial  order,  and  hence  can  be 
extended  to  a  total  order,  <.  Notice  that  each  <x  and  <p  is  compatible  with  -<. 

Suppose  ~<  is  not  a  partial  order.  Then  we  can  construct  a  cycle  e1  •  ...  •  en,  where  e1  = 
en,  such  that  e.,  -<  e2  -<  ...  en,  where  eM  and  e^  1  <  /  <  n,  are  related  by  some  <x  or  <p. 

The  contradiction  is  immediate  if  no  pair  is  related  by  a  <p.  because  then  all  relations  are 
induced  by  the  same  <x,  which  is  assumed  to  be  a  total  order.  Otherwise,  the  cycle  of 
operations  can  be  relabeled  so  that  e,  <p  e2,  for  some  process  P.  Because  processes  are 
sequential,  the  response  of  e1  precedes  the  invocation  of  e2,  and  because  all  relations  are 
consistent  with  -<,  the  invocation  of  e2  precedes  the  response  of  en,  which  is  identical  to 
the  response  of  ev  Hence  the  response  of  e,  precedes  itself,  a  contradiction.  I 

Henceforth,  we  consider  only  histories  involving  single  objects,  omitting  object  names  from  events. 

Locality  is  important  because  it  allows  concurrent  systems  to  be  designed  and  constructed  in  a 


In  databases,  serializability  is  often  provided  in  conjunction  with  failure  atomicity,  ensuring  that  a  transaction  interrupted  by 
a  failure  will  have  no  effect. 
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modular  fashion;  linearizable  objects  can  be  implemented,  verified,  and  executed  independently.  A 
concurrent  system  based  on  a  non-local  correctness  property  must  either  rely  on  a  centralized 
scheduler  for  all  objects,  or  else  additional  constraints  must  be  placed  on  objects  to  ensure  that  they 
follow  compatible  scheduling  protocols. 

Locality  should  not  be  taken  for  granted;  the  literature  includes  proposals  for  both  alternative 
correctness  properties  that  are  not  local.  For  example,  Lamport’s  notion  of  sequential  consistency  is 
not  a  local  property.  Consider  the  following  sequential  history  H,  in  which  processes  A  and  B  operate 
on  queue  objects  p  and  q.  For  brevity,  matching  responses  are  shown  on  the  same  lines  as 
invocations. 

p  Enq(x)/Ok()  A 
q  Enq(y)/Ok()  B 
q  Enq(x)/Ok()  A 
p  Enq(y)/Ok()  B 
p  Deq()/Ok(y)  A 
q  Deq()/Ok(x)  B 

H|p  and  H|q  are  not  legal  sequential  histories,  but  they  are  sequentially  consistent,  although  H  itself  is 
not. 

Also,  serializability  and  Lamport’s  strengthened  notion  of  serializability  are  both  non-local.  In  the 
example  above,  H|p  and  H|q  are  each  serializable  in  either  sense,  but  H  itself  is  not. 

3.3.  Linearized  Values 

Non-determinism  is  inherent  in  the  notion  of  linearizability:  (1)  For  each  H,  there  may  be  more  than 
one  extension  H’  satisfying  the  two  conditions,  Li  and  L2,  and  (2)  for  each  extension  H’,  there  may  be 
more  than  one  linearization  S.  We  call  the  value  of  an  object  at  the  end  of  a  linearization  a  linearized 
value.  Since  a  given  history  may  have  more  than  one  linearization,  an  object  may  have  more  than  one 
linearized  value  at  the  end  of  a  history.  We  let  L/n(H)  denote  the  set  of  linearized  values  of  H. 

Informally,  a  history’s  linearized  values  represent  the  object's  possible  values  from  the  point  of  view  of 
an  external  observer.  Figure  3-1  shows  a  queue  history  with  its  set  of  linearized  values  after  each 
event.  (We  use  []  for  emp  and  [x,y]  for  ins(ins(emp,  x),y),  etc.)  Initially,  only  the  empty  queue  is 

*  r 

associated  with  the  empty  history.  After  the  invocation  of  Enq(x),  there  are  two  linearized  values, 
since  the  enqueue  may  or  may  not  have  taken  effect.  After  the  invocation  of  Enq(y),  there  are  five 
linearized  values:  either  Enq  may  or  may  not  have  occurred,  and  if  both  have  occurred,  either 
ordering  is  possible.  After  the  response  to  Enq(y),  y  is  known  to  have  been  enqueued,  and  after  the 
response  to  Enq(x),  both  x  and  y  must  have  been  enqueued,  although  their  order  remains  ambiguous 
until  x  is  dequeued. 
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History 

Linearized  values 

{[]} 

Enq(x)  A 

{[].[x]} 

Enq(y)  B 

{[],[x],[y],[x,y],[y,x]} 

Ok()B 

{[yj.[x.y].[y.x]} 

Ok()  A 

{[x,y],[y,x]} 

Deq()  C 

{[x],[y]i[x,y],[y,x]} 

Ok(x)  C 

{[y]} 

Figure  3*1:  Linearized  Values 


4.  Reasoning  About  Concurrent  Objects 

So  far,  linearizability  is  defined  in  terms  of  histories.  This  historic  (!)  characterization  is  useful  for 
motivating  the  property,  and  for  demonstrating  properties  such  as  locality,  but  it  is  awkward  for 
verification.  For  linearizable  histories,  however,  assertions  about  interleaved  histories  can  be 
transformed  into  assertions  about  sets  of  sequential  histories,  and  thus,  sets  of  values.  The 
transformed  assertions  can  be  stated  and  proved  with  the  help  of  familiar  axiomatic  methods 
developed  for  sequential  programs.  Sometimes  it  will  be  necessary  or  more  convenient  to  reason  in 
terms  of  sets  of  sequential  histories,  (see  Poss  below),  and  sometimes,  simply  in  terms  of  sets  of 
values,  e.g.,  Lin(H)  for  some  history  H.  In  this  section,  we  show  how  we  reason  about  properties  of 
concurrent  objects  by  reasoning  in  terms  of  sets  of  linearizations;  in  the  next  section,  we  how  how  we 
do  verification  by  reasoning  in  terms  of  sets  of  values. 

A  possibility  for  a  history  H  is  a  pair  <S,  P>  where  S  is  a  linearization  of  H  and  P  is  the  set  of  pending 
invocations  not  completed  to  construct  S.  We  let  Poss  denote  the  set  of  possibilities  of  a  history.  If  we 
only  care  about  the  final  value  of  S,  we  use  <v,  P>  to  denote  one  of  the  <S,  P>  such  that  the  value  of  S 
is  v.  The  relationship  between  the  set  of  possibilities  and  set  of  linearized  values  for  a  given  history  H 
is  that  for  each  <v,  P>  €  Poss,  v  €  Lin(H). 

H's  set  of  possibilities,  and  hence  set  of  linearized  values,  is  captured  by  the  following  three  axioms. 
The  following  closure  axiom  states  that  if  S  is  a  linearization  of  H,  ‘inv  A'  is  a  pending  invocation  in  H 
that  is  not  completed  to  form  S,  and  S'  =  S  •  inv  A  •  res  A  is  a  legal  sequential  history,  then  S'  is  also  a 
linearization  of  H. 

Axiom  C: 

<S, P>  €  Poss 

=>  [(V  'inv  A'  €  P)  (3  res)  S  •  inv  A  •  res  A  is  legal 
=>  <S  •  inv  A  •  res  A,  P  -  {inv  A}>  €  Poss] 

The  following  invocation  axiom  states  that  any  linearization  of  H  is  also  a  linearization  of  H  •  inv  A. 
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Axiom  I: 

{<S,  P>  €  Poss} 
inv  A 

{<S,  P  U  {inv  A}>  €  Poss’} 

Let  last(S,  A)  be  the  response  to  A's  last  invocation  in  the  sequential  history  S,  and  let  A  €  P  mean 
there  exists  an  invocation  i  such  that  ‘i  A’  €  P.  The  following  response  axiom  states  that  any 
linearization  of  H  in  which  the  pending  ‘inv  A’  is  completed  with  ‘res  A’  is  also  a  linearization  of  H  •  res 
A. 

Axiom  R: 

{<S,  P>  €  Poss  and  A  €  P  and  res  A  =  last(S,  A)} 
res  A 

{<S,  P>  €  Poss’} 

For  a  given  history  with  m  events,  we  use  Poss,  to  denote  the  set  of  possibilities  for  the  ith  prefix  of  H, 
for  0  <  i  <  m.  A  derivation  that  shows  that  <v,  P>  €  Possm  is  a  sequence  of  implications  of  the  form: 
<vQ,  PQ>  €  PosSq 

=>  <v.,  P.>  €  Possk 

=>  <v  P  >  €  Poss_. 

n  n  m 

where  vn  =  v,  Pn  =  P,  and  each  implication  is  justified  by  Axiom  C,  I,  or  R. 

Intuitively,  a  derivation  is  like  a  history.  Instead  of  reasoning  about  histories  directly,  however,  we  use 
axiomatic  proof  techniques  to  reason  about  derivations— each  implication  in  a  derivation  is  like  a  step 
in  a  proof  where  each  step  in  the  proof  is  justified  by  some  axiom.  For  each  operation  of  a  typed 
object,  Axiom  C  is  instantiated  to  yield  type-specific  closure  axioms,  and  similarly  for  Axioms  I  and  R. 

In  any  derivation  showing  H  is  linearizable,  the  order  in  which  Axiom  C  is  applied  to  pending 
invocations  induces  a  valid  linearization  ordering  on  the  operations  of  H.  Informally,  the  following 
lemma  states  that  an  operation  must  appear  to  "take  effect”  at  some  instant  between  its  invocation 
and  its  response. 

Lemma  2:  Let  ‘inv  A’  be  the  ith  event  of  H,  and  let  the  matching  response  ‘res  A’  be  the  jth 
event.  Any  derivation  showing  that  H  is  linearizable  must  include  an  application  of  Axiom 
C  to  infer: 

<v,  P>  €  PossR  =>  <v‘,  P  -  {inv  A}>  €  Possk 
for  some  k,  i  <  k  <  j. 

Proof:  The  only  way  to  infer  anything  about  Poss,  from  PossM  is  to  apply  Axiom  I  as 
follows: 

<u,  Q>  €  Poss, ,  =>  <u,  O  U  {inv  A}>  €  Poss, 

Later  in  the  derivation,  the  only  way  to  infer  anything  about  Poss^  from  Poss  1  is  by 
applying  Axiom  R: 
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<w,  R>  €  Poss. 0  and  ‘inv  A'  <£  R  <w,  R>  €  Poss.. 

Between  these  two  steps,  the  only  way  to  remove  ‘inv  A’  from  the  set  of  pending 
invocations  is  by  applying  Axiom  C  as  shown  above.  I 

We  use  Lemma  2  and  type-specific  instantiations  of  Axioms  C,  I,  and  R  to  prove  properties  about 
concurrent  objects.  First,  we  look  at  concurrent  registers,  then  concurrent  queues. 


4.1 .  Concurrent  Registers 

Here  are  axioms  for  Read  and  Write  operations  for  all  concurrent  register  objects,  r: 

{true} 

Read()/Ok(v) 

{fetch(r)  ■  fetch(r’)  =>  v} 


{true} 

Write(v)/Ok() 
{fetch(r’)  »  v} 


where  the  Larch  Shared  Language  specification  for  register  values  is: 

RVals:  trait 
introduces 
new:  — »  R 
store:  R,  V  -t  R 
fetch:  R  — *  V 
dontcare:  -» V 

constrains  R  so  that  for  all  r:  R,  v:  V 
fetch(new)  =  dontcare 
fetch(store(r,  v))  a  v 

These  sequential  axioms  can  be  combined  with  our  linearizability  condition  to  prove  assertions  about 
the  interleavings  permitted  by  concurrent  registers.  Notice  that  we  do  not  need  to  assume  that  all 
values  written  to  the  register  are  unique. 


Every  value  read  was  written,  but  not  overwritten. 

Theorem  3:  If  the  last  event  of  H  is  the  Read  response  'Ok(v)  A',  then  H  includes  an  earlier 
Write  invocation  ‘Write(v)  B‘,  and  if  the  Write  operation  is  complete,  then  it  precedes  no 
other  complete  Write  operation. 

Proof:  If  the  Read  response  is  the  mth  event  of  H,  then  <v,  P>  €  Possm.  In  any  derivation 
showing  that  H  is  linearizable,  the  last  application  of  Axiom  C  for  a  Write  invocation  must 
have  the  form: 

<u,  Q>  €  Possk  =*>  <v,  0  -  {Write(v)  B}>  €  Possk 
This  inference  is  legal  only  if  B’s  Write  is  pending  at  event  k.  By  Lemma  2,  if  B's  Write  is 
complete  and  precedes  another  complete  Write,  then  the  derivation  must  include  a  later 
application  of  Axiom  C  for  a  Write  invocation,  contradicting  our  assumption  that  B's  was 
the  last.  I 
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Register  values  are  persistent  in  the  absence  of  Write  operations. 

Theorem  4:  An  interval  in  a  history  is  a  sequence  of  contiguous  events.  If  /  is  an  interval 
that  does  not  overlap  any  Write  operations,  then  all  Read  operations  that  lie  within  /  return 
the  same  value. 

Proof:  Pick  two  Read  operations  that  lie  within  the  interval  that  return  distinct  values  v  and 
v’.  If  H  is  linearizable,  there  exists  a  derivation  showing  that  <v,  P>  €  Possj  and  <v\  Q>  6 
Possk  where  one  Read  is  pending  at  event  j  and  the  other  at  event  k,  where  j  <  k.  The  only 
way  to  deduce  that  <v\  Q>  €  Possk  from  <v,  P>  €  PosSj  is  to  apply  Axiom  C  to  a  pending 
Write  at  some  intermediate  step,  which  is  permissible  only  if  some  Write  operation  overlaps 
/.  I 


4.2.  Concurrent  Queues 

The  proofs  of  the  following  theorems  about  concurrent  queues  use  Axioms  E  and  D  of  Figure  2-1  and 
the  trait  of  Figure  2-2.  We  make  use  of  the  following  fact  about  queues: 

Lemma  5:  If  Q  is  a  sequential  queue  history  where  x  is  enqueued  before  y,  then  x  is  not 
dequeued  after  y. 

Proof:  From  Axioms  E  and  D.  I 

Theorem  6:  If  Enq(x)/Ok(),  Enq(y)/Ok<),  Deq()/Ok(x),  and  Deq()/Ok(y)  are  complete 
operations  of  H  such  that  x’s  Enq  precedes  y’s  Enq,  then  y’s  Deq  does  not  precede  x’s 
Deq.  (I.e.,  either  x’s  Deq  precedes  y’s,  or  they  are  concurrent.)  , 

Proof:  Pick  a  derivation  showing  H  is  linearizable.  Lemma  2  implies  that  Axiom  C  is 
applied  to  all  four  invocations,  since  the  operations  are  complete.  Moreover,  because  the 
enqueue  of  x  precedes  the  enqueue  of  y,  the  derivation  must  apply  Axiom  C  to  x’s  Enq 
first.  By  Lemma  5,  the  derivation  must  also  apply  Axiom  C  to  x’s  Deq  before  y's  Deq,  thus 
y's  Deq  operation  cannot  precede  x’s  Deq.  I 

Gottlieb  et  al.  [7]  adopt  the  property  proved  in  Theorem  6  as  the  desired  correctness  property  for  their 
concurrent  queue  implementation.  The  difficulty  of  reasoning  directly  about  interleaved  histories  is 
illustrated  by  observing  that  Theorem  6  by  itself  is  incomplete  as  a  concurrent  queue  specification, 
since  it  does  not  prohibit  implementations  in  which  enqueued  items  spontaneously  disappear  from 
the  queue,  or  new  items  spontaneously  appear.  Such  behavior  is  easily  ruled  out  by  the  following  two 
theorems: 

Items  do  not  spontaneously  vanish  from  the  queue. 

Theorem  7:  If  the  Enq  of  x  precedes  the  Enq  of  y,  and  if  y  has  been  dequeued,  then  either 
x  has  been  dequeued  or  there  is  a  pending  Deq  concurrent  with  the  Deq  of  y. 

Proof:  Any  derivation  showing  that  H  is  linearizable  must  use  Axiom  C  to  enqueue  x 
before  enqueuing  y,  hence  by  Lemma  5  the  derivation  must  apply  Axiom  C  to  dequeue  x 
before  it  can  dequeue  y.  The  Deq  invocation  that  removed  x  may  have  returned,  or  it  may 
be  pending.  I 
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Items  do  not  spontaneously  appear  in  the  queue. 

Theorem  8:  If  x  has  been  dequeued,  then  it  was  enqueued,  and  the  Deq  operation  does 
not  precede  the  Enq, 

Proof:  Any  derivation  showing  that  (q,  P)  €  Possk  and  x  =  first(q)  must  include  an  earlier 
application  of  Axiom  C  showing  that: 

<q’,  P’>  €  Possj  =>  <ins(q',x),  P'  -  {Enq(x)  A}>  €  PosSj 
which  is  legal  only  if  the  invocation  has  occurred.  I 

4.2.1 .  Two  Lemmas  about  Concurrent  Queues 

Before  we  turn  to  verification  of  implementations,  we  state  and  prove  two  lemmas  about  queues  that 
will  be  used  to  help  verify  the  queue  implementation  of  the  next  section. 

In  a  derivation,  an  Enq  inference  for  x  is  an  instantiation  of  Axiom  C  of  the  form: 

<q.,  P.>  €  Possk  <ins(qj,x),  P.  -  {Enq(x)  A}>  €  Poss,^ 

A  Deq  inference  is  defined  analogously. 

Two  inferences  commute  in  a  derivation  if  their  order  can  be  reversed  without  invalidating  the 
derivation.  A  derivation  showing  that  <q,  P>  €  Possm  is  in  canonical  form  if  each  Enq  inference  for  an 
item  in  q  occurs  “as  late  as  possible,''  i.e.,  it  does  not  commute  with  the  next  inference  in  the 
derivation. 

Lemma  9  implies  that  if  x  is  in  q,  the  event  following  the  Enq  inference  for  x  is  either  the  return  event 
for  x,  or  the  return  event  for  an  item  that  follows  x  in  q. 

Lemma  9:  If  5  is  a  canonical  derivation  showing  that  <q,  P>  €  Possm,  and  x  is  an  item  in  q, 
then  the  inference  following  the  Enq  inference  for  x  is  either  the  Enq  inference  for  the  item 
following  x  in  q,  or  an  application  of  Axiom  R  for  the  matching  response  to.Enq(x). 

Proof:  We  show  that  x’s  Enq  inference  commutes  with  all  other  inferences.  If  the  next 
inference  in  5  is  the  Deq  inference  for  an  item  y,  then  5  cannot  be  canonical,  because: 

<q  ,  P.>  €  Possk 

=*>  <ins(qj,x),  P.  -  {Enq(x)  A}>  €  Poss,, 

=>  <rest(ins(q.,x)),  P.  -  {Enq(x)  A,  Deq()  B}>  €  Poss. 

J  J  K 

is  equivalent  to: 

<q ,  P  >  €  Possk 

=>  <rest(qj)),P.  -  {Deq()  B}>  €  Possk 

=*>  <ins(rest(qj,x),  P  -  (Enq(x)  A,  Deq()  B}>  £  Poss,, 

Here,  we  exploit  the  observation  that  because  x  is  in  q,  q.  must  be  non-empty,  hence 
restfinsfqj.x))  *  insfrestfq^.x). 

Similar  arguments  show  that  x’s  Enq  inference  commutes  with  all  applications  of  Axiom  I, 
and  with  all  applications  of  Axiom  R  for  non-matching  response  events.  Finally,  we 
observe  that  any  Enq  inference  for  an  item  in  q  must  follow  all  Enq  inferences  for  items 
whose  Deq  inferences  appear  in  5.  I 
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Lemma  10  states  that  we  can  consider  equivalence  classes  of  queues  rather  than  individual  queues. 

Lemma  10:  If  <q,  P>  €  Possm,  and  q*  is  a  queue  value  constructed  by  rearranging  the 
items  of  q  in  an  order  consistent  with  the  partial  precedence  order  of  their  Enq  operations, 
then  <q*.  P>  €  Possm. 

Proof:  We  argue  inductively  that  if  there  exists  a  canonical  n-step  derivation  that  <q,  P>  € 
Possm,  there  also  exists  a  canonical  n-step  derivation  that  <q*,  P>  E  Possm. 

Base  step:  Trivial  for  n  *  0  where  q  =  emp. 

Induction  hypothesis:  If  <q,  P>  €  Possm  has  a  canonical  derivation  of  length  less  than  n, 
<q*,  P>  E  Possm  has  a  canonical  derivation  of  the  same  length. 

Induction  step:  Given  an  n-step  canonical  derivation  8  that  <q,  P>  €  Possm,  we  construct 

an  n-step  canonical  derivation  5*  that  <q\  P>  €  Possm.  If  the  last  step  of  5  is  an 

application  of  Axiom  I  or  R,  then  qp =  qn,  and  we  have  an  n-1  step  canonical  derivation 

that  <qn,  Pn1>  €  Possm  r  The  induction  hypothesis  yields  an  n-1  step  canonical  derivation 

that  <q\  Pn1>  €  Possm1,  and  reapplying  the  last  inference  yields  a  derivation  that  (q*,  Pn) 

€  Poss  . 
m 

Otherwise,  the  last  step  of  8  is  an  Enq  or  Deq  inference,  which  can  be  discarded  to  yield  an 
n-1  step  canonical  derivation  that  <qn.r  Pn1>  E  Possm.  Suppose  the  discarded  inference 
is  an  Enq  inference  for  x  by  A.  Define  qn-1  *  to  be  q*  with  x  deleted  from  the  queue.  By  the 
induction  hypothesis,  there  exists  an  n-1  step  canonical  derivation  Sn1  *  that  <qn1  \  Pn1> 

€  Possm.  If  x  is  the  last  element  in  q*,  then  we  construct  5*  using  Axiom  C  to  enqueue  x  to 
qn  Otherwise,  let  y  be  the  item  immediately  following  x  in  q\  let  B  be  the  process  that 
enqueued  y,  and  let  the  jth  inference  of  8n *  be  the  Enq  inference  for  y.  By  Lemma  9,  the 
next  event  in  the  history  is  the  return  event  for  some  item  z  that  follows  x  in  q*.  Since  z’s 
Enq  operation  is  concurrent  with  x’s  Enq  operation,  ’Enq(x)  A’  €  P.*.  We  construct  5*  as 
follows:  all  inferences  before  j  are  unchanged,  and  the  jth  inference  of  5*  is  x’s  Enq 
inference: 

<q.\  P*>€Possk 

=*  flnstaj'.x),  P.*  -  {Enq(x)  A}>  €  Possk 

which  is  justified  because  'Enq(x)  A'  is  in  P.\  For  j  <  k  <  n,  the  kth  inference  of  5*  is  the 
(k-l)st  inference  of  8,  with  insfq/.x)  substituted  for  q.*  and  Pk*  for  Pk.  To  show  that  8*  is 
sound,  we  must  check  that  each  axiom’s  pre-conaition  is  still  satisfied.  The  result  is 
immediate  for  applications  of  Axioms  I  and  R,  as  well  as  for  Enq  inferences,  since  it  is 
always  legal  to  append  an  Enq  to  a  history.  For  Deq  inferences,  we  observe  that  every 
dequeued  item  was  enqueued  before  x,  hence  at  each  Deq  inference,  the  value  at  the  front 
of  the  queue  is  unchanged.  Finally,  8*  is  canonical  because  the  Enq  inferences  for  x  and 
y  do  not  commute. 

Suppose  the  discarded  inference  was  a  Deq  inference,  where  first(qn  ,)  =  x.  Define  qn  ,  * 
to  be  the  queue  value  such  that  first(qn  }*)  =  x  and  rest(qn  ,*)  =  q*.  By  the  induction 
hypothesis,  there  exists  a  canonical  n-1  step  derivation  8n  that  <qn  Pn  €  Possm- 
Since  ’Deq()  A’  €  Pn1,  we  can  use  Axiom  C  to  extend  8  to  a  canonical  derivation  8* 
such  that  <rest(qn1*),  Pn1  -  {Deq()  A}>  =  <q*.  Pn>  €  Possm.  I 
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5.  Verification:  Abstraction  Functions  Revisited 

This  section  proposes  a  verification  methodology  for  implementations  of  linearizable  concurrent 
objects.  We  propose  a  model  for  data  type  implementations  and  define  a  correctness  condition  in 
Section  5.1.  We  give  an  example  of  a  queue  implementation  and  prove  its  correctness  in  Section  5.2. 

As  a  first  step,  let  us  review  how  to  verify  a  sequential  data  type  implementation  [14,  9].  An 
implementation  consists  of  an  abstract  type  A,  the  type  being  implemented,  and  a  representation  (or 
rep)  type  R,  the  type  used  to  implement  A.  The  subset  of  R  values  that  are  legal  representations  is 
characterized  by  a  predicate  called  the  rep  invariant,  3:  R  — ♦  bool.  The  meaning  of  a  legal  rep  is  given 
by  an  abstraction  function,  A:  R  — ►  A,  defined  only  for  values  that  satisfy  the  invariant. 

An  abstract  operation  a  is  implemented  by  a  sequence,  p,  of  rep  operations  that  carries  the  rep  from 
one  legal  value  to  another,  perhaps  passing  through  intermediate  values  where  the  abstraction 
function  is  undefined.  The  rep  invariant  is  thus  part  of  both  the  pre-condition  and  post-condition  for 
each  operation's  implementation;  it  must  be  satisfied  between  abstract  operations,  although  it  may  be 
temporarily  violated  while  an  operation  is  in  progress.  An  implementation,  p,  of  an  abstract  operation, 
a,  is  correct  if  there  exists  a  rep  invariant,  3,  and  abstraction  function,  A,  such  that  whenever  p 
carries  one  legal  rep  value  r  to  another  r',  a  carries  the  abstract  value  from  J.(r)  to  .A(r’). 

For  sequential  objects,  the  rep  invariant  must  hold  at  the  start  and  finish  of  each  abstract  operation, 
but  it  may  be  violated  while  an  operation  is  in  progress.  For  concurrent  objects,  however,  it  no  longer 
makes  sense  to  view  the  object’s  representation  as  assuming  meaningful  values  only  between 
abstract  operations.  Instead,  operations  must  be  implemented  to  behave  correctly  for  rep  values  that 
reflect  the  incomplete  effects  of  concurrent  operations.  To  capture  the  effects  of  interleaving,  the 
notions  of  rep  invariant  and  abstraction  function  must  be  extended  to  encompass  transient 
representation  values  reflecting  the  incomplete  effects  of  concurrent  operations. 

5.1 .  Definitions 

An  implementation  is  a  set  of  histories  in  which  events  of  two  objects,  a  representation  object  r  of  type 
R  and  an  abstract  object  a  of  type  A,  are  interleaved  in  a  constrained  way:  for  each  history  H  in  the 
implementation,  (1)  the  subhistories  H|r  and  H|a  satisfy  the  usual  well-formedness  conditions;  and  (2) 
for  each  process  P,  each  rep  operation  in  H|P  lies  within  an  abstract  operation.  Informally,  an 
abstract  operation  is  implemented  by  the  sequence  of  rep  operations  that  occur  within  it. 

An  implementation  is  correct  if  for  every  history  H  in  the  implementation,  H|a  is  linearizable. 

The  rep  invariant  3  must  be  continually  satisfied  and  the  abstraction  function  continually  defined  not 
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only  between  abstract  operations,  but  also  between  each  step  in  the  sequence  of  rep  operations 
implementing  an  abstract  operation.  The  non-determinism  inherent  in  a  concurrent  computation 
gives  our  abstraction  functions  a  different  flavor  from  their  sequential  counterparts.  We  redefine  the 
abstraction  function  so  that  it  maps  each  rep  value  to  a  (non-empty)  set  of  abstract  values: 

M  R-+2* 

To  show  correctness,  the  verification  technique  for  sequential  implementations  is  generalized  as 
follows.  Assume  that  the  implementation  of  r  is  correct,  hence  H|r  is  linearizable  for  all  H  in  the 
implementation.  Let  Lin(H|x)  be  the  set  of  linearized  values  for  x  in  H.  Our  verification  technique 
focuses  on  showing  the  following  property: 

For  all  r  in  Lin(H|r),  3(r)  holds  and  .A(r)  C  Lin(Hja) 

This  condition  implies  that  Lin(H|a)  is  non-empty,  hence  that  H|a  is  linearizable.  Note  that  the  set 
inclusion  is  necessary  in  one  direction  only;  there  may  be  linearized  abstract  values  that  have  no 
corresponding  representation  values.  Such  a  situation  arises  when  the  representation  “chooses”  to 
linearize  concurrent  operations  in  one  of  several  permissible  ways. 


5.2.  Queue  Example 

Consider  the  following  concurrent  queue  implementation.  The  representation  is  a  record  with  two 
components:  items  is  an  array  having  a  low  bound  of  1  and  a  (conceptually)  infinite  high  bound,  and 
back  is  the  (integer)  index  of  the  next  unused  position  in  items. 

rep  =  record  {back:  int,  items:  array  [item]} 

Each  element  of  items  is  initialized  to  a  special  null  value,  and  back  is  initialized  to  1 . 


Enq  and  Deq  are  implemented  as  follows: 

Enq  =  proc  (q:  cvt,  x:  Item) 

i:  int  :=  INC(q.back)  %  Allocate  a  new  slot. 

STORE(q.items[i],  x)  %  Fill  it. 

end  enq 

Deq  =  proc  (q:  cvt)  returns  (item) 
while  true  do 

range:  int  :=  FETCH( q . back)-l 
for  i:  int  in  1.. range  do 

x:  item  :=  SWAP( q . i tems[ i ] , null ) 

If  x  ~=  null  then  return(x)  end 

end 
end 
end  deq 


An  Enq  execution  occurs  in  two  atomic  steps:  an  array  slot  is  reserved  by  atomically  incrementing 
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back,  and  the  new  item  is  stored  in  items.  2  Deq  traverses  the  array  in  ascending  order,  starting  at 
index  1.  For  each  element,  it  atomically  swaps  null  with  the  current  contents  If  the  value  returned  is 
not  equal  to  null,  Deq  returns  that  value,  otherwise  it  tries  the  next  slot.  If  the  index  reaches  back-1 
without  encountering  a  non-null  element,  the  operation  is  restarted.  All  atomic  steps  can  be 
interleaved  with  steps  of  other  operations.  For  brevity,  we  leave  out  the  axioms  and  traits  for  records 
and  arrays,  which  can  be  straightforwardly  given  (see  [20, 10]). 

Let  R  be  a  complete  history  for  a  queue  representation,  and  let  items(R)  be  the  set  of  items  stored  in 

the  array,  but  not  swapped  out.  Let  -<R  be  the  partial  order  such  that  x  -<R  y  if  the  STORE  operation 

for  x  precedes  the  INC  operation  for  y  in  R.  If  r  is  a  linearized  value  for  R,  items(r)  =  items(R) 

corresponds  to  the  set  of  non-null  items  in  the  array,  and  -<  =  -<R  is  their  partial  order.  Finally,  we 

ex'.and  the  trait  of  Figure  2-2  by  defining  the  total  order,  <  and  the  operator,  items,  such  that: 

first(q)  <q  first(rest(q)) 
items(emp)  =  {} 
items(ins(q,  e))  =  {e}  U  items(q) 

The  implementation  has  the  following  rep  invariant: 

5(r)  a  (r.back  >  1) 

A  (i  >  r.back  =*  r.items[i]  =  null) 

A  (lbound(r. items)  =  1) 

and  the  following  abstraction  function: 

•A(r)  =  {q  |  items(r)  =  items(q)  A  -<r  Q  <q} 

In  other  words,  a  queue  representation  value  corresponds  to  the  set  of  queues  whose  items  are  the 
items  in  the  array,  sorted  in  some  order  consistent  with  the  precedence  order  of  their  Enq  operations. 
Thus,  our  implementation  allows  for  an  item  with  a  higher  index  to  be  removed  from  the  array  before 
an  item  with  a  lower  index,  but  only  if  the  items  were  enqueued  concurrently. 

Figure  5-1  shows  a  sequence  of  abstract  operations  of  Figure  3-1  along  with  their  implementing 
sequence  of  rep  operations.  Column  two  is  the  set  of  abstracted  linearized  rep  values.  Column  three 
is  the  set  of  linearized  abstract  values.  Our  correctness  criterion  requires  showing  that  each  set  in 
column  two  is  a  subset  of  the  corresponding  set  in  column  three. 

Figure  5-2  shows  the  Enq  and  Deq  implementation  annotated  with  assertions  that  are  true  before  and 
after  each  abstract  invocation  and  response  and  each  rep  operation.  It  is  convenient  to  keep  as 
implicit  auxiliary  data  the  partial  order,  -<R,  on  items  in  the  array,  and  the  set,  P,  that  contains  the 
invocations  that  have  not  yet  been  applied  to  the  rep. 
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INC  returns  the  value  of  its  argument  from  before  the  invocation,  not  the  new  incremented  value. 


History 


Ur€Lin(H|r)“^r) 


Lin(H|a) 


{[]} 

Enq(x)  A 

{[]} 

{[].[x]} 

INC(q.back)  A 

{[]} 

{[].[x]} 

Ok(1)  A 

{[]} 

{[].[x]} 

STORE(q.items[1  ],x)  A 

{[],[*]) 

{[].[x]} 

Enq(y)  B 

{[].[x],[y].[x.y],[y.x]} 

INC(q.back)  B 

{[],[x]} 

{[},[x],[y],[x,y],[y,x]} 

Ok(2)  B 

{[].[x],[y],[x,y],[y,x]} 

ST ORE(q .  items[2]  ,y)  B 

{[]>[x],[y],[x,y]} 

{[].[x].[y],[x,y],[y,x]} 

OkQB 

{[y].[x,y]} 

{[]i[x],[y],[x,y],[y,x]} 

Ok()  B 

{[y].[x,y]} 

{[y].[x.y],[y.x]} 

Ok()  A 

{[x.y]} 

{[y].[x,y],[y,x]} 

Ok()  A 

{[x.y]} 

{[x,y],[y,x]} 

DeqQC 

{[x.y]} 

{[x.y],[y,x],[x],[y]} 

FETCH(q.back)  C 

{[x,y]} 

{[x,y],[y,x],[x],[y]} 

Ok  (2)  C 

{[x.y]} 

{[x,y),[y,x],[x],[y]} 

SWAP(q.items[l],null)  C 

{[x,y],[y]> 

{[x,y],[y,x],tx],[y]} 

Ok(x)  C 

{[y]} 

{[x,y],[yx],[x],[y]} 

Ok(x)  C 

{[y]} 

{[y]} 

Flgu  re  5- 1 :  A  Queue  History 

If  I  is  a  set  of  items  partially  ordered  by  define: 

(I,  -<)  »  {q  1 1  *  items(q)  and  -<  C  <q> 
and 

<0,  -<),  P>  =  {<q.  P>  I  q  €  (I,  -<)} 

The  partially  ordered  set  of  queue  items,  (I,  -<),  captures  the  non-quiescent  abstract  state  of  the 
queue,  i.e.,  the  possible  values  of  the  queue  while  there  are  concurrent  Enq  and  Deq  operations  or 
pending  invocations.  Notice  that  we  can  rewrite  the  abstraction  function  as  J.(r)  *  (items(r),  -<r).  <(l, 
-<),  P>  identifies  each  of  the  possible  sets  of  queue  values  with  a  set  of  pending  invocations,  thereby 
forming  a  set  of  (queue)  possibilities. 

Lemma  1 1 :  If  x  is  a  maximal  element  with  respect  to  x  €  I.  ‘Enq(x)  A’  i  P,  and  <(l,  -<), 

P  U  (Enq(x)  A}>  C  Poss.  then  <(l  U  {x},  -<),  P>  C  Poss. 

Proof:  Pick  any  q  €  (I,  -<),  and  any  q'  €  (I  U  {x},  -<).  Since  <q,  P  U  {Enq(x)  A}>  €  Poss, 
<ins(q,x),  P>  €  Poss  by  Axiom  C.  Since  ins(q,x)  is  an  element  of  (I  U  {x},  -<),  <q',  P>  € 

Poss  by  Lemma  10.  I 

Lemma  12:  If  <(l,  -<),  P  U  {Deq()  A}>  C  Poss,  then  for  all  x  such  that  x  is  a  minimal 
element  of  I,  <(l  -  {x},  -<),  P>  C  Poss. 

Proof:  Pick  any  q  €  (I,— <)  such  that  first(q)  =  x,  and  any  q’  €  (I  -  {x},  -<).  Since  <q,  P  U 
(Deq()  A}>  €  Poss,  <rest(q),  P>  €  Poss  by  Axiom  C.  Since  rest(q)  is  an  element  of  (I  -  {x}, 

-<),  <q’,  P>  €  Poss  by  Lemma  10.  I 
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{true} 

Enq  =  proc  (q:  cvt,  x:  item) 

{P'  =  PU  (Enq(x)  A}} 

{true} 

i:  int  :=  INC(q.back) 

{q.back'  =  q.back  +  1  A  /  =  q.back} 

V EnqMA’tP } 

STORE( q . i tems[ i ] .  x) 

(P‘  =  P  -  {Enq(x)  A}  A  indexfq. items',  x)  =  /  A 
x  €  max(items(q‘))  A  q.back  <  q.back'} 

X  A  concurrent  Enq  might  bump  q.back  before  the  store. 

{true} 

end  Enq 

{'EnqMA'iP') 

{true} 

Oeq  3  proc  (q:  cvt)  returns  (item) 

{ P '  *  PU  {DeqOA}} 

while  true  do 

{true} 

range:  int  :*  FETCH(q.back)-l 
{range  -  q. back-1} 

for  1 :  int  in  1.  .  range  do 

{true} 

x:  item  : *  SWAP( q . i terns [ i ] , nul 1 ) 

P'  =  P  -  (DeqO  A}  A  (x  =  null  V  x  €  min(items(q')))} 

if  x  null  then  return(x)  end 
end 

end 
end  Deq 

Figure  5-2:  Annotated  Queue  Implementation 
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Lemma  1 1  will  allow  us  to  show  that  the  set  of  linearized  queue  values  does  not  change  over  a  STORE 
operation  and  similarly,  Lemma  12,  for  a  SWAP  operation,  by  using  -<r  for  -<  and  by  recalling  that  for 
each  <v,  P>  €  Poss,  v  is  a  linearized  value.  We  use  the  next  two  lemmas  to  satisfy  the  conditions  of 
the  previous  two  lemmas. 

Lemma  1 3:  Enq  enqueues  an  item  x  that  is  maximal  with  respect  to  -<  . 

Proof:  Suppose  not.  Then  after  the  STORE  there  exists  some  non-null  item  y  such  that  x 
-<r  y.  By  definition  of  -<r,  we  have  that  the  STORE  for  x  precedes  the  INC  for  y.  Thus, 
indexfq. items,  x)  <  indexfq. items,  y).  Since  indexfq. items,  x)  =  q.back,  then  q.back  < 
indexfq. items,  y).  By  the  rep  invariant,  for  all  i,  i  >  q.back,  q.items[i]  =  null  so  that 
q.items[index(q. items,  y)]  =  null,  i.e.,  y  -  null,  a  contradiction.  I 

Lemma  1 4:  Deq  removes  and  returns  an  item  x  that  is  minimal  with  respect  to  -Cr. 

Proof:  Suppose  not.  Then  there  exists  non-null  y  such  that  y  -<r  x.  For  x  to  be  returned 
from  within  the  for  loop,  the  SWAP  of  x  must  happen  before  the  STORE  of  y.  The  STORE 
of  x  must  happen  before  the  SWAP  of  x  and  the  INC  of  x  before  the  STORE  of  x,  so  then 
the  INC  of  x  must  occur  before  the  STORE  of  y,  which  implies  that  x  and  y  are 
incomparable,  a  contradiction.  I 

Here  is  a  proof  of  correctness. 

Theorem  1 5:  The  queue  implementation  is  correct. 

Proof:  Assuming  every  rep  history  is  finearizable,  we  need  to  show  that  every  queue 
history,  Hjq,  is  linearizable.  It  suffices  to  show  that  the  “subset”  property, 
Ur€un(H|r)^r)  £  Lin(H|q),  remains  invariant  over  abstract  invocation  and  responses  and 
over  complete  rep  operations.  Thus,  it  can  be  conjoined  to  the  pre-  and  post-conditions  of 
Figure  5-2  as  justified  by  the  Owicki-Gries  proof  method  [23].  Axioms  I  and  R  give  us  the 
result  for  abstract  invocation  and  response  events.  INC  and  FETCH  leave  the  abstraction 
function  the  same.  Thus,  we  are  left  with  two  cases,  STORE  and  SWAP.  By  Lemma  13  we 
know  that  STORE  adds  a  maximal  item  and  thus,  we  can  apply  Lemma  1 1  to  show  that  the 
subset  property  is  preserved.  Similarly,  by  Lemma  14  we  know  that  SWAP  removes  a 
minimal  item  and  thus,  we  can  apply  Lemma  12  to  show  that  the  subset  property  is 
preserved. 

Proofs  of  non-interference  between  pre-  and  post-conditions  and  that  the  rep  invariant 
holds  are  straightforward.  I 

An  Aside:  Handling  Critical  Regions 

An  implementation  without  critical  regions,  such  as  the  previous  queue  example,  can  be  verified  by 
defining  a  rep  invariant  that  is  continually  satisfied,  and  an  abstraction  function  that  is  continually 
defined.  That  is,  each  step  of  the  sequence  of  representation  operations  implementing  an  abstract 
operation  must  preserve  the  rep  invariant,  and  exactly  one  such  step  causes  the  operation’s  effects  to 
become  visible  to  other  operations. 


If  an  operation  creates  a  temporary  inconsistency,  perhaps  hidden  from  concurrent  operations  by 
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some  form  of  critical  region,  then  it  may  not  be  possible  to  define  a  meaningful  abstraction  function 
directly  in  terms  of  the  representation.  Such  inconsistencies  can  be  eliminated  by  augmenting  the 
representation  with  appropriate  auxiliary  data,  and  similar  proof  techniques  as  used  in  our  queue 
example  can  be  used  for  verification. 

6.  Related  Work 

The  axiomatic  approach  to  specifying  sequential  programs  has  its  origins  in  Hoare’s  early  work  on 
verification  [13]  and  later  work  on  proofs  of  correctness  of  implementations  of  abstract  data  types 
[14],  where  first  order  predicate  logic  pre-  and  post- conditions  are  used  for  the  specification  of  each 
operation  of  the  type.  The  algebraic  approach,  which  defines  data  types  to  be  heterogeneous 
algebras  [3],  uses  axioms  to  specify  properties  of  programs  and  abstract  data  types,  but  the  axioms 
are  restricted  to  equations.  Much  work  has  been  done  on  algebraic  specifications  for  abstract  data 
types  [1, 6,  8,  29,  4,  5,  28,  16];  we  use  more  recent  work  on  Larch  specifications  [10,  11]  for  sequential 
program  modules. 

Owicki  and  Gries  extended  Hoare’s  axiomatic  approach  to  handle  concurrent  programs  [24]  by 
including  axioms  for  general  concurrent  programming  language  constructs.  Apt  et  al.  [2]  use  a 
similar  approach  for  CSP  [15]  in  particular.  These  approaches  differ  from  ours  by  focusing  on  control 
structures  such  as  the  parallel  operator,  leaving  data  uninterpreted. 

Lamport  [18]  has  proposed  a  model  and  assertion  language  for  specifying  properties  of  concurrent 
objects.  His  approach  is  more  general  than  ours,  as  it  addresses  liveness  as  well  as  safety  properties, 
and  non-linearizable  as  well  as  linearizable  behavior.  Our  approach,  however,  focuses  exclusively  on 
a  subset  of  concurrent  computations  that  we  believe  to  be  the  most  interesting  and  useful. 

Our  notion  of  linearizability  generalizes  and  unifies  similar  notions  found  in  specific  examples  in  the 
literature.  Lamport  gives  a  specification  for  a  linearizable  concurrent  queue  permitting  one 
enqueuing  process  and  one  dequeuing  process.  The  queue's  state  is  defined  as  a  collection  of  state 
functions  mapping  time  to  algebraic  values.  One  state  function  takes  on  queue  values;  it  may  change 
only  while  operations  are  in  progress.  The  values  of  the  otKer  ■'f-'te  functions  are  used  as  control 
flags  to  prevent  operations  from  taking  effect  more  than  once.  His  queue-valued  state  function 
roughly  corresponds  to  our  abstraction  function  except  that  the  state  function  maps  to  a  single  queue 
value,  not  a  set  of  queue  values.  His  technique,  therefore,  could  not  be  used  to  prove  our  queue 
implementation  correct  because  of  the  inherent  nondeterminism  in  our  example. 

Misra  [22]  has  proposed  an  axiomatic  treatment  of  concurrent  hardware  registers  in  which  the 
register's  value  is  expressed  as  a  function  of  time.  Restricted  to  registers,  our  axiomatic  treatment  is 
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equivalent  to  his  in  the  sense  that  both  characterize  the  full  set  of  linearizable  register  histories. 
Theorems  3  and  4  capture  two  properties  of  Misra’s  registers.  Misra’s  explicit  use  of  time  in  axioms  is 
appropriate  for  hardware,  where  reasoning  in  terms  of  the  register’s  hypothetical  value  is  useful  as  a 
guide  to  hardware  designers.  Our  approach,  however,  is  also  appropriate  for  objects  implemented  in 
software,  as  we  have  found  that  reasoning  directly  in  terms  of  partial  orders  generalizes  more 
effectively  to  data  types  having  a  richer  set  of  operations. 

Gottlieb  et  al.  [7]  have  investigated  architectural  support  for  implementing  concurrent  objects  without 
critical  regions,  an  approach  illustrated  by  our  linearizable  implementation  of  a  FIFO  queue.  They 
present  a  linearizable  implementation  of  a  concurrent  queue  (different  from  ours).  The  correctness 
condition  asserted  for  their  queue,  however,  is  the  property  stated  in  Theorem  6,  which  by  itself  is 
incomplete  as  a  concurrent  queue  specification  since  it  does  not  prohibit  implementations  in  which 
enqueued  items  spontaneously  disappear  from  the  queue,  or  new  items  spontaneously  appear.  As 
shown  by  Theorems  7  and  8,  such  anomalous  behavior  is  easily  ruled  out  by  our  queue  axioms  and 
the  assumption  of  linearizabiiity. 

7.  Discussion 

Without  linearizabiiity,  the  meaning  of  an  operation  may  depend  on  how  it  is  interleaved  with 
concurrent  operations.  Specifying  such  behavior  would  require  a  more  complex  specification 
language,  as  well  as  producing  more  complex  specifications  (e.g.,  Lamport’s  [18]).  Linearizabiiity 
provides  the  illusion  that  each  operation  takes  effect  instantaneously  at  some  point  between  its 
invocation  and  its  response,  implying  that  the  meaning  of  a  concurrent  object's  operations  can  still  be 
given  by  pre-  and  post-conditions. 

The  role  of  linearizabiiity  for  concurrent  objects  is  analogous  to  the  role  of  serializability  for  data  base 
theory:  it  facilitates  certain  kinds  of  formal  (and  informal)  reasoning  by  transforming  assertions  about 
complex  concurrent  behavior  into  assertions  about  simpler  sequential  behavior.  Like  serializability, 
linearizabiiity  is  a  safety  property;  it  states  that  certain  interleavings  cannot  occur,  but  makes  no 
guarantees  about  what  must  occur.  Other  techniques,  such  as  temporal  logic  [27,  25,  12,  18,  21], 
must  be  used  to  reason  about  liveness  properties  like  fairness  or  priority. 

An  implementation  of  a  concurrent  object  need  not  realize  all  interleavings  permitted  by  linearizabiiity, 
but  all  interleavings  it  does  realize  must  be  linearizable.  The  actual  set  of  interleavings  permitted  by  a 
particular  implementation  may  be  quite  difficult  to  specify  at  the  abstract  level,  being  the  result  of 
engineering  trade  offs  at  lower  levels.  As  long  as  the  object’s  client  relies  only  on  linearizabiiity  to 
reason  about  safety  properties,  the  object’s  implementor  is  free  to  support  any  level  of  concurrency 
that  appears  to  be  cost-effective. 
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Linearizabiiity  provides  benefits  for  specifying,  implementing,  and  verifying  concurrent  objects  in 
multiprocessor  systems.  Rather  than  introducing  complex  new  formalisms  to  reason  directly  about 
concurrent  computations,  we  feel  it  is  more  effective  to  transform  problems  in  the  concurrent  domain 
into  simpler  problems  in  the  sequential  domain. 
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